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(57) An apparatus and method for an improved 
asynchronous communication channel between a 
transmitter (400) and a receiver (500) having separate 
clocks. The invention provides a simple implementation 
that solves both the overflow and the underflow problem 
using the same mechanism, and reduces complexity by 
elimination of the control split between the two clock do- 
mains. A first embodiment of the invention is a method 
for preventing packet underflow and packet overflow for 
packets sent across an asynchronous link between a 
transmitter (400) and a receiver (500), including a buffer 
(502) that can store a number of packets greater than 
an ideal number of packets. The method includes send- 
ing a predetermined number of drop-me warning pack- 
ets (616) and sending one or more drop-me packets 
(620) from the transmitter (400) to the receiver (500), 
receiving the predetermined number of drop-me warn- 
ing packets and the one or more drop-me packets in the 
buffer (502), compensating for packet overflow when 
the number of packets is greater than the ideal number 
of packets in the buffer (502) by skipping at least one 
drop-me packet, and compensating for packet under- 
flow in the buffer (502) when the number of packets is 
less than the ideal number of packets by stalling access 
to the buffer (502) for one or more clock cycles. A sec- 
ond embodiment of the invention is an asynchronous 
link for packets sent between a transmitter (400) having 
a first clock and a receiver (500) having a second clock, 
including a buffer (502) to receive the first clock from the 
transmitter (400) and receive from the transmitter (400) 



a number of packets equal to or different to a predeter- 
mined ideal number of packets, a write pointer (514), 
and a read pointer (510), and a read pointer control cir- 
cuit (512) to change the read pointer, wherein the buffer 
(502) can receive drop-me packets, and the read pointer 
(510) can skip a drop-me packet in the buffer (502). 
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Description 

BACKGROUND OF THE INVENTION 

Field of the Invention 

[0001 ] This invention relates generally to an improve- 
ment in asynchronous communication, and more spe- 
cifically to preventing packet underflow and overflow 
without undue circuit complexity. 

Description of the Prior Art 

[0002] In a system with multiple integrated circuit (IC) 
chips operating at different core frequencies, if the trans- 
mitting chip clock frequency is different from the receiv- 
ing chip clock frequency, there may be packet overflow 
or underflow problems. A packet overflow problem oc- 
curs when the transmitting chip clock frequency is high- 
er than the receiving chip clock frequency, and some 
packets are dropped at the receiving chip. A packet un- 
derflow problem occurs when the transmitting chip clock 
frequency is lower than the receiving chip clock frequen- 
cy, and the receiving chip has some clock cycles when 
there are no valid data packets from the transmitting 
chip. These packet underflow episodes are sometimes 
referred to as bubbles. 

[0003] One prior art solution involves performing the 
packet processing (namely error correction code decod- 
ing, type decoding, initialization, and other basic func- 
tions) on the receiving chip side using the clock of the 
transmitting chip. This requires a significant amount of 
circuitry in the receiving chip that is controlled by the 
transmitting chip's clock. One drawback of this prior art 
approach is that the control circuitry gets split between 
the two clock domains, making the design complex, 
since the two clock domains have to work together in 
tandem. It also means that some control and status reg- 
isters, including error-logging registers, need to be 
present in the transmitting chip clock domain. 
[0004] FIG. 1 illustrates a prior art approach for trans- 
mission and reception of packets between a transmitting 
chip 130 and a receiving chip 132. Transmitting chip 
core logic 118 sends data signals to outbound process- 
ing circuit 1 1 4, and sends and receives clock and control 
signals from error logs and other control registers 116. 
In the transmitting chip clock domain 140, inbound 
processing circuit 1 02 receives transmitting chip clock 
1 20 and data 1 22 from outbound processing circuit 1 1 4, 
and provides packets to a synchronizing First-ln- First- 
Out (FIFO) buffer 104, which is read using a receiving 
chip clock (not shown) and written using the transmitting 
chip clock 120 Storage FIFO 106 is entirely in the re- 
ceiving chip clock domain 1 50 and receives packets 
from synchronizing FIFO 104. Error logs and other con- 
trol registers 1 08 send and receive signals from inbound 
processing circuit 102, and send and receive signals 
from synchronizing circuitry 1 1 0. Synchronizing circuitry 



1 1 0 is used to access these error logs and other control 
registers 108 from the receiving chip clock domain 1 50. 
Receiving chip core logic 112 sends and receives sig- 
nals from synchronizing circuitry 110, and receives data 
5 from storage FIFO 1 06. 

[0005] This prior art approach handles the packet un- 
derflow problem by ensuring that an adequate number 
of packets in the transaction are gathered by the storage 
FIF0 106 before sending the transaction to the receiving 
10 chip core logic 112. A packet overflow problem is han- 
dled by ensuring that the transmitting chip 130 sends a 
number of idle packets at fixed intervals of time, so that 
the receiving chip 1 32 can catch up without requiring the 
idle packets to go through its synchronizing FIFO buffer 
15 104 into the receiving chip clock domain 150. 

[0006] For example, a prior art approach for handling 
the packet overflow problem would set up the transmit- 
ting chip 130 to send three or more idle packets every 
1000 clock cycles, regardless of whether or not these 
20 1 000 clock cycle intervals occur in the middle of a trans- 
action. Furthermore, the prior art approach for handling 
the packet underflow problem would require a hardware 
and software mechanism to stop pulling out packet en- 
tries from the storage FIFO buffer until a certain number 
25 of packet entries are available. Therefore, prior art so- 
lutions for overflow and underflow packet problems re- 
quire separate hardware and software for overflow and 
underflow, with hardware in the packet path both before 
and after the synchronizing FIFO buffer, and require 
30 substantially continuous processing of the packets with 
this hardware and software, even in the middle of trans- 
actions. 

[0007] There are several drawbacks to this prior art 
approach. There is a lot of extra circuitry required to syn- 

35 chronize the registers in the transmitting chip clock do- 
main 140 to the receiving chip clock domain 150. This 
extra circuitry introduces greater complexity into the de- 
sign. This approach also makes parts of the circuitry, 
such as the status and control registers in the transmit- 

40 ting chip clock domain 1 40 inaccessible, when the trans- 
mitting chip 130 is not present, has not been powered 
on, or is in some kind of reset state. The system software 
has to operate successfully despite these possibilities; 
this can require very complex software that is difficult to 

45 write and difficult to debug. This is also not a good so- 
lution from a high reliability/availability perspective, 
since the transmitting chip 130 not only affects the link 
to which the receiving chip 132 is connected, it also af- 
fects parts of the receiving chip 132, rendering these 

so parts inaccessible. 

[0008] One way to get around the latency problem is 
to design a core in the receiving chip 132 that can deal 
with bubbles caused by packet underflow. However, this 
will significantly complicate the design. In addition, in- 

55 creasing design complexity of a system (and the number 
of components that can fail) generally reduces the over- 
ail reliability of the system. 

[0009] What is needed is a simple implementation 
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that solves both the packet overflow problem and the 
packet underflow problem using the same mechanism, 
and which reduces the complexity of the solution by 
elimination of the control split between the receiving chip 
and transmitting chip clock domains. 

SUMMARY OF THE INVENTION 

[0010] One object of the invention is to provide a sim- 
ple implementation that solves both the overflow prob- 
lem and the underflow problem using the same mecha- 
nism, and which reduces the solution complexity by 
elimination of the control split between the receiving chip 
and transmitting chip clock domains. 
[0011] A first aspect of the invention is directed to a 
method for preventing packet underflow and packet 
overflow for packets sent across an asynchronous link 
between a transmitter and a receiver, wherein the re- 
ceiver includes a buffer that can store a number of pack- 
ets greater than an ideal number of packets. The meth- 
od includes sending a predetermined number of drop- 
me warning packets from the transmitter to the receiver 
across the asynchronous link, sending one or more 
drop-me packets from the transmitter to the receiver 
across the asynchronous link, receiving the predeter- 
mined number of drop-me warning packets and the one 
or more drop-me packets in the buffer, compensating 
for packet overflow when the number of packets in the 
buffer is greater than the ideal number of packets by 
skipping at least one drop-me packet in the buffer, so 
that the ideal number of packets is substantially main- 
tained in the buffer, and compensating for packet under- 
flow when the number of packets is less than the ideal 
number of packets by stalling access to the buffer for 
one or more clock cycles, so that the ideal number of 
packets is substantially maintained in the buffer. 
[0012] A second aspect of the invention is directed to 
an asynchronous link for packets sent between a trans- 
mitter having a first clock and a receiver having a second 
clock. The asynchronous link includes a buffer to re- 
ceive the first clock from the transmitter and receive from 
the transmitter a number of packets equal to or different 
from a predetermined ideal number of packets, a read 
pointer containing a read address for the buffer and a 
read pointer control circuit to change the read address, 
wherein the buffer can receive drop-me packets and the 
read address in the read pointer can skip a drop-me 
packet in the buffer and a write pointer containing a 
write address for the buffer. 

[001 3] These and other objects and advantages of the 
invention will become apparent to those skilled in the art 
from the following detailed description of the invention 
and the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0014] FIG. 1 illustrates a prior art approach for trans- 
mission and reception of packets between two chips. 



[0015] FIG. 2A shows a 72-bit header packet, with 
eight bits for ECC checking, and five bits for encoding 
the type of packet. 

[0016] FIG. 2B shows a 72-bit data packet with eight 
5 bits for ECC checking, and the remaining 64 bits avail- 
able for data bits. 

[0017] FIG. 3 illustrates an overview of one preferred 
embodiment of the invention. 

[0018] FIG. 4 shows a transmitting chip in accordance 
10 with one preferred embodiment of the invention. 

[0019] FIG. 5 shows a receiving chip in accordance 
with one preferred embodiment of the invention. 
[0020] FIG. 6 illustrates a flow chart of a method used 
by a transmitting chip, which employs both drop-me 
is warning packets and drop-me packets sent by the trans- 
mitting chip, in accordance with one embodiment of the 
invention^ 

[0021] FIG. 7 illustrates a flow chart of a method used 
by a receiving chip, which employs both drop-me warn- 
20 jng packets and drop-me packets received by the re- 
ceiving chip, in accordance with one embodiment of the 
invention. 

[0022] FIG. 8 illustrates a flow chart of a method used 
by a transmitting chip, which employs only drop-me 

25 packets sent by the transmitting chip, in accordance with 
another embodiment of the invention. 
[0023] FIG. 9 illustrates a flow chart of a method used 
by a receiving chip, which employs only drop-me pack- 
ets received by the receiving chip, in accordance with 

30 another embodiment of the invention. 

DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENTS OF THE INVENTION 

35 [0024] This invention provides an improved method 
and apparatus for asynchronous communication be- 
tween a transmitting chip and a receiving chip with dif-*' 
ferent core clock frequencies. 

[0025] In one preferred embodiment of the invention, 

*o a transaction is made up of one header packet by itself, 
or a header packet followed by or one or more data 
packets. The packets in a transaction are sent on con- 
secutive clock cycles. A special type of header packet 
known as an idle packet is sent if there are no transac- 

4 $ tions available to be sent. 

[0026] This preferred embodiment of the invention al- 
so includes a special synchronizing sequence, which is 
made up of two new types of header packets. The first 
of the new header packet types is called a drop-me 

50 warning packet. The second of the new header packet 
types is called a drop-me packet. The synchronizing se- 
quence consists of a series of drop-me warning packets 
followed by a series of drop-me packets. The transmit- 
ting chip periodically sends a synchronizing sequence 

55 between transactions. 

[0027] FIG. 2A shows a 72-bit header packet 200, 
with eight bits for ECC checking (bits 71 to 64), and five 
bits for encoding the type of packet (bits 4 to 0). Five 
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bits is sufficient to encode 32 types, including idle pack- 
ets, drop-me warning packets, drop-me packets, and 
header packets for a variety of transaction types. Typi- 
cally, a five-bit field is sufficient, because there are ap- 
proximately twenty types of transactions in typical appli- 
cations. This encoded type field also indicates to the re- 
ceiving chip the number of data packets, which follow 
the header packet to form the current transaction. The 
header packet preferably includes other bit fields iden- 
tifying the source and destination of the transaction (bits 
63 to 5). 

[0028] FIG. 2B shows a 72-bit data packet 250, with 
eight bits for ECC checking (bits 71 to 64), and the re- 
maining 64 bits available for data bits (bits 63 to 0). A 
packet typically ranges from 32 to 144 bits, and prefer- 
ably ranges from 64 to 72 bits, but a packet could have 
more or less bits, depending on the type of transaction 
that is divided into packets. 

[0029] FIG. 3 illustrates an overview of one preferred 
embodiment of the invention in which a transmitting chip 
400 is connected to a receiving chip 500. Transmitting 
chip core logic 118 provides data signals to outbound 
processing circuit 312, and clock and control signals to 
outbound initialization and drop-me control logic 316. 
Both outbound processing circuit 312 and outbound in- 
itialization and drop-me control logic 316 provide data 
inputs to multiplexer MUX 314. Synchronizing First-In- 
First-Out (FIFO) buffer 302 receives data signal 122 
from the output of multiplexer MUX 314, and receives 
transmitting chip clock signal 1 20 from outbound initial- 
ization and drop-me control logic 316. Synchronizing 
FIFO buffer 302 and inbound initialization and miscella- 
neous control logic 308 are the receiving chip compo- 
nents subject to the transmitting chip clock domain 340. 
Synchronizing FIFO buffer 302 includes a storage por- 
tion, and a write pointer. A read pointer for synchronizing 
FIFO buffer 302 is found in inbound processing circuit 
304 in the receiving chip clock domain 350. The inbound 
processing circuit 304 sends and receives signals from 
status and control registers and error log 310, and sends 
received packets to storage FIFO 106. Receiving chip 
core logic 1 1 2 reads the packets stored in storage FIFO 
106. 

[0030] FIG. 4 shows a transmitting chip 400 in accord- 
ance with one preferred embodiment of the invention. 
Transmitting chip 400 comprises an ECC encoder 402, 
which provides packets 41 0 from the core of the trans- 
mitting chip to multiplexer MUX 404. Multiplexer MUX 
404 also receives drop-me packets 412 and drop-me 
warning packets 414 to be selectively provided on the 
data output 1 22 of MUX 404 to be sent to the receiving 
chip 500 (shown in FIG. 5), in conjunction with transmit- 
ting chip clock 120 provided by clock buffer 416. MUX 
404 is controlled by drop-me state machine 406, which 
sends a reset signal to drop-me counter 408, and re- 
ceives a dropme_sync_count signal from drop-me 
counter 408. 

[0031] FIG. 5 shows a receiving chip 500 in accord- 



ance with one preferred embodiment of the invention. 
Receiving chip 500 comprises a synchronizing FIFO 
buffer 502, processing circuitry 504 to check ECC and 
perform type decode, multiplexer MUX 506, drop-me 

5 control logic 508, read pointer circuitry 510, write pointer 
circuitry 514, and synchronizer 516. Synchronizing 
FIFO buffer 502 receives data signals 122 and ciock 120 
from the transmitting chip 400 (shown in FIG. 4), pro- 
vides read data output to processing circuitry 504, re- 

10 ceives a read address from read pointer circuitry 510, 
and receives a write address from write pointer circuitry 
514. Write pointer circuitry 514 also provides an input 
signal to synchronizer 51 6. The read address output of 
read pointer circuitry 510 is subtracted from the output 

15 of synchronizer 516 at subtractor 518. The output of 
subtractor51 8 provides the number of entries in the syn- 
chronizing FIFO buffer 502, which is an input to subtrac- 
tor 520, which subtracts the ideal number of entries, sig- 
nal 526, from this input. The output of subtractor 520 is 

20 coupled to drop-me control logic 508. Adder 512 adds 
an increment amount from drop-me control logic 508 to 
the value of the read pointer 510, and sends the incre- 
mented value back to the read pointer 510. Drop-me 
control logic 508 also receives a type decode output 

25 from processing circuitry 504, and provides a control in- 
put signal to multiplexer MUX 506. This control input sig- 
nal selects either an idle packet on signal 522 or the 
packet output of processing circuitry 504 to be output as 
signal 524 to the core (not shown) of receiving chip 500. 

30 [0032] This embodiment of the invention relies on the 
transmitting chip 400 sending a synchronizing se- 
quence, which is made up of a predetermined number 
(which can be programmable) of drop-me warning pack- 
ets, followed by a predetermined number (which can be 

35 programmable) of drop-me packets. Typically, the syn- 
chronizing sequence indicates that a transaction is com- 
pleted and that a fixed number of transmitting chip 400 
clock cycles have passed since the last synchronizing 
sequence. 

40 [0033] When the receiving chip 500 receives a drop- 
me warning packet, the receiving chip 500 determines 
that the transmitting chip is indicating it is time for the 
receiving chip 500 to compensate for any clock frequen- 
cy mismatches. The drop-me control 508 in the receiv- 

45 ing chip clock domain 350 keeps a certain number of 
entries in the synchronizing FIFO buffer 502. This is 
known as the ideal number of entries that will be main- 
tained in the synchronizing FIFO buffer 502. After initial- 
ization, processing block 504 starts pulling entries out 

so of the synchronizing FIFO buffer 502 when it sees the 
ideal number of entries. If the transmitting chip 400 and 
receiving chip 500 ciock frequencies are identical, this 
ideal number of entries will be in the synchronizing FIFO 
buffer 502 when the synchronizing sequence is re- 

55 ceived. In this case : the processing circuitry 504 keeps 
consuming entries from the synchronizing FIFO buffer 
in normal operation. 

[0034] However, if the transmitting chip 400 clock fre- 
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quency is slower than the receiving chip 500 clock fre- 
quency, then there can be less than the ideal number of 
entries, because the receiving chip 500 is consuming at 
a faster pace than the transmitting chip 400 is sending. 
In this case, the processing block will stop consuming 
entries from the synchronizing FIFO buffer 502 for the 
number of cycles that correspond to the number of en- 
tries not received, so that the ideal number of entries in 
the synchronizing FIFO buffer 502 will be maintained. 
When the consumption of entries from the synchroniz- 
ing FIFO buffer 502 is stopped, idle packets can be ar- 
tificially injected, if the downstream core logic expects 
something to be given to it in every clock cycle. Drop- 
me packets and drop-me warning packets are treated 
as idle packets. 

[0035] If the transmitting chip 400 clock frequency is 
higher than the receiving chip 500 clock frequency, then 
the number of entries in the synchronizing FIFO buffer 
502 can be in excess of the ideal number of entries. In 
this case, advancing the read pointer of the synchroniz- 
ing FIFO buffer 502 skips the excess number of entries, 
so that the ideal number of entries is maintained. 
[0036] The number of drop-me warning packets in 
every synchronizing sequence depends on the latency 
between the reading of the synchronizing FIFO buffer 
502, and drop-me control logic 508 taking action to mod- 
ify or freeze the read pointer. This delay is known as the 
drop-me processing delay. For example, if it takes two 
cycles after pulling the first drop-me warning packet for 
the drop-me control logic 508 to modify its read pointer 
due to pipelining in the processing unit, then the drop- 
me processing delay is two receiving chip 500 clock cy- 
cles. In this case, three drop-me warning packets fol- 
lowed by the first drop-me packet will be needed. Then 
it can be assumed that the drop-me control logic 508 will 
have enough time to act when the first drop-me packet 
is about to go out. The number of drop-me packets is a 
design choice. A larger number of drop-me packets will 
require that the synchronizing sequence will be needed 
less frequently, since more catch-up is available in each 
synchronizing sequence. However, this also means that 
the size of the synchronizing FIFO buffer 502 will need 
to be increased by an equivalent number of entries, 
since a higher tolerance for overflows and underflows is 
needed. The design choice will depend on the intended 
frequency of operation, the fraction by which the two 
clocks can deviate, the latencies in the processing unit, 
the latency from the core of transmitting chip 400 to the 
core of receiving chip 500, and the maximum length of 
a transaction in terms of packets. 
[0037] I n the most preferred embodiment of the inven- 
tion, the synchronizing sequence in every period should 
be contiguous and can be initiated only on a transaction 
boundary, and the transmitting chip 400 has to wait for 
the end of the current transaction before it can start 
sending the synchronizing sequence. The drop-me 
counter starts counting the cycles of the next period, 
even though the transmitting chip 400 waits to send the 



synchronizing sequence. As soon as the current trans- 
action ends, the transmitting chip 400 starts the syn- 
chronizing sequence. The synchronizing FIFO buffer 
502 should be designed to handle the case when the 
5 synchronizing sequence may be delayed by the longest 
transaction (i.e., the maximum number of packets). In 
general, it is a good idea to add a few entries to the 
number of packets derived mathematically for the size 
of the synchronizing FIFO buffer 502 as a safe design 
10 practice. Since the synchronizing sequence is sent in 
between transactions, there will not be packet overflow 
or underflow correction in the middle of a transaction. 
[0038] For example, a synchronizing sequence con- 
sisting of a contiguous group of three drop-me warning 

is packets and three drop-me packets could be sent by the 
transmitting chip 400 approximately every 1500 clock 
cycles in a window of time that begins after the end of 
one transaction and before the beginning of a new trans- 
action. As a specific example, if the transaction strad- 

20 dling the 1500 clock cycle mark consists of a header 
packet and four data packets, and the fourth data packet 
happens to be sent on clock cycle 1502 : then the first 
drop-me warning packet would be sent on clock cycle 
1503, the second drop-me warning packet would be 

25 sent on clock cycle 1504, and so forth. This process of 
using the transmitting chip 400 to send synchronizing 
sequences would then be repeated every 1500 trans- 
mitting chip clock cycles. And if it happens that the trans- 
action just before clock cycle 1500 sends the last data 

30 packet on clock cycle 1499, then the first drop-me warn- 
ing packet would be sent on clock cycle 1500, and so 
forth. 

[0039] FIG. 6 illustrates a flow chart of a method used 
by atransmitting chip 400, which employs both drop-me 

35 warning packets and drop-me packets sent by the trans- 
mitting chip 400, in accordance with one embodiment of 
the invention. In operation 602, a power on reset state 
or reset state is entered. In operation 604, 
dropme_sync_count, a variable to determine when the 

40 transmitting chip 400 should start sending a synchroniz- 
ing sequence, is initialized to zero. In operation 606, the 
value of dropme_sync_count is incremented by one. In 
operation 608, the value of dropme_sync_count is com- 
pared to the value of FREQ_DROPME - 1 , a predeter- 

45 mined number of clock cycles that must occur before 
the transmitting chip 400 should start sending the syn- 
chronizing sequence. If the value of 
dropme_sync_count is less than the value of 
FREQJDROPME - 1 , then it is not yet time and opera- 

50 tion 606 is repeated. If the value of dropme_sync_count 
is greater than or equal to the value of FREQ_DROPME 
- 1 , then it is time and operation 61 0 is next. In operation 
610, dropme_sync_count is set to zero. In operation 
612, a test is made to determine if the transmitting chip 

55 400 is in the middle of a transaction. If it is in the middle 
of a transaction, then operation 614 is next, the value of 
dropme_sync_count is incremented by one, and oper- 
ation 612 is repeated. If it is not in the middle of a trans- 
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action, operation 616 is next, where a drop-me warning 
packet is sent, and the value of dropme_sync_count is 
incremented by one. In operation 618, there is a test to 
determine if the required number of drop-me warning 
packets was sent. If the required number was not sent, 
then operation 616 is repeated. If the required number 
was sent, then operation 620 is next, where a drop-me 
packet is sent and the value of dropme_sync_count is 
incremented. In operation 622, a test determines if the 
required number of drop-me packets was sent. If the re- 
quired number was sent, the method is done and oper- 
ation 606 is next. If the required number was not sent, 
then operation 620 is repeated. 
[0040] FIG. 7 illustrates a flow chart of a method used 
by a receiving chip 500, which employs both drop-me 
warning packets and drop-me packets received by the 
receiving chip 500, in accordance with one embodiment 
of the invention. In operation 702, a power on reset state 
or reset state is entered. In operation 704, read_pointer, 
a synchronizing FIFO buffer read address variable, is 
initialized to zero. In operation 706 : the receiving chip 
500 waits for one clock cycle. In operation 708, the value 
of number_entries_syncFIFO, a variable that equals the 
synchronized address in the write pointer minus the ad- 
dress in the read pointer, is compared to the value of 
ideaLentries_syncFIFO, a predetermined ideal number 
of packets in the synchronizing FIFO buffer, if the value 
of number_entries_syncFIFO is less than the value of 
ideaLentries_syncFIFO, then operation 706 is repeated 
to wait another cycle. If the value of 
number_entries_syncFIFO is greater than or equal to 
the value of ideaLentries_syncFIFO, then operation 
710 is next In operation 710, a packet entry is pulled 
from the synchronizing FIFO and the address in the 
read_pointer is incremented. In operation 712, a test is 
made to determine if this is a drop-me warning packet. 
If it is not a drop-me warning packet, then operation 71 0 
is repeated. If it is a drop-me warning packet, operation 
714 is next, where the value of 
number_entries_syncFIFO is compared to the value of 
ideal_entries_syncFIFO. An error will be logged in an 
error log if the value of number_entries_syncFIFO - 
ideal_entries_syncFIFO exceeds the tolerated range of 
deviation from ideal, i.e., the number of drop-me packets 
in a synchronizing sequence. If the value of 
number_entries_syncFIFO is greater than the value of 
ideai_entries_syncFIFO, then operation 716 is next, 
where a packet entry is pulled from the synchronizing 
FIFO, the address in read_pointer is incremented by 
one, plus the value of number_entries_syncFIFO, mi- 
nus the value of ideal_entries_syncFIFO. Then opera- 
tion 722 is next. In operation 714, if the value of 
number_entries_syncFIFO is less than or equal to the 
value of ideal_entries_syncFlFO, then operation 718 is 
next. In operation 718, there is a test to determine if the 
value of number_entries_syncFIFO is less than the val- 
ue of ideaLentries_syncFIFO. If the value of 
number_entries_syncFIFO is not less than the value of 



ideal_entries_syncFIFO, then operation 722 is next. If 
the value of number_entries_syncFIFO is less than the 
value of ideaLentries_syncFIFO, then operation 720 is 
next. In operation 720, an idle packet is fed to the core 
5 of receiving chip 500, without pulling any packet from 
the synchronizing FIFO, and the test of operation 71 8 is 
repeated. In operation 722, a packet entry is pulled from 
the synchronizing FIFO and the address in the 
read_pointer is incremented. The next operation is op- 
to eration 724, in which a test is made to determine if this 
is a drop-me warning packet. If it is not a drop-me warn- 
ing packet, then operation 71 0 is next. If it is a drop-me 
warning packet, operation 722 is repeated. 
[0041] The preceding method described the use of a 
15 synchronizing sequence, which consists of drop-me 
warning packets and drop-me packets. An alternate em- 
bodiment would use only drop-me packets, where the 
first drop-me packet would be interpreted as a drop-me 
warning packet. Subsequent drop-me packets would be 
20 treated as described above. 

[0042] FIG. 8 illustrates a flow chart of a method used 
by a transmitting chip 400, which employs only drop-me 
packets sent by the transmitting chip 400, in accordance 
with another embodiment of the invention. In operation 
25 802, a power on reset state or reset state is entered. In 
operation 804, dropme_sync_count, a variable to deter- 
mine when the transmitting chip 400 should start send- 
ing a synchronizing sequence, is initialized to zero. In 
operation 806, the value of dropme_sync_count is in- 
30 cremented by one. In operation 808, the value of 
dropme_sync_count is compared to the value of 
FREQJDROPME - 1 , a predetermined number of clock 
cycles that must occur before the transmitting chip 400 
should start sending a synchronizing sequence. If the 
35 value of dropme_sync_count is less than the value of 
FREQ_DROPME - 1 , then operation 806 is repeated. If 
the value of dropme_sync_count is greater than or equal 
to the value of FREQ_DROPME - 1 , then operation 810 
is next. In operation 810, the value of 
40 dropme_sync_count is set to zero. In operation 812, a 
test is made to determine if the transmitting chip 400 is 
in the middle of a transaction. If it is in the middle of a 
transaction, then operation 814 is next, the value of 
dropme_sync_count is incremented by one, and oper- 
45 ation 81 2 is repeated. If it is not in the middle of a trans- 
action, operation 820 is next, where a drop-me packet 
is sent and the value of dropme_sync_count is incre- 
mented. In operation 822, a test determines if the re- 
quired number of drop-me packets was sent. If the re- 
so quired number was sent, the method is done, and oper- 
ation 806 is next. If the required number was not sent, 
then operation 820 is repeated. 

[0043] FIG . 9 illustrates a flow chart of a method used 
by receiving chip 500, which employs only drop-me 
55 packets received by receiving chip 500, in accordance 
with another embodiment of the invention. In operation 
902, a power on reset state or reset state is entered. In 
operation 904, read_pointer, a synchronizing FIFO buff- 
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er read address variable, is initialized to zero. In opera- 
tion 906, the receiving chip 500 waits for one clock cycle. 
In operation 908, the value of 
number_entries_syncFIFO, a variable that equals the 
synchronized address in the write pointer minus the ad- s 
dress in the read pointer, is compared to the value of 
ideaLentries_syncFIFO, a predetermined ideal number 
of packets in the synchronizing FIFO buffer. If the value 
of number_entries_syncFIFO is less than the value of 
ideal_entries_syncFIFO, then operation 906 is repeated 10 
to wart another cycle. If the value of 
number_entries_syncFIFO is greater than or equal to 
the value of ideal_entries_syncFIFO, then operation 
910 is next. In operation 910, a packet entry is pulled 
from the synchronizing FIFO and the address in '5 
read_pointer is incremented. In operation 912, a test is 
made to determine if this is a drop-me packet. If it is not 
a drop-me packet, then operation 910 is repeated. If it 
is a drop-me packet, operation 914 is next, where the 
value of number_entries_syncFIFO is compared to the 20 
value of ideal_entries_syncFI FO . An error will be logged 
in an error log if the value of number_entries_syncFIFO 
- ideaLentries_syncFIFO exceeds the tolerated range 
of deviation from ideal, i.e., the number of drop-me pack- 
ets in a synchronizing sequence minus one, minus the 25 
drop-me processing delay described above. If the value 
of number_entries_syncFIFO is greater than the value 
of ideal_entries_syncFIFO, then operation 916 is next, 
where a packet entry is pulled from the synchronizing 
FIFO, the address in read_pointer is incremented by 30 
one and the value of number_entries_syncFIFO : minus 
the value of ideal_entries_syncFIFO. Then operation 
922 is next. In operation 914, if the value of 
number_entries_syncFIFO is less than or equal to the 
value of ideal_entries_syncFIFO, then operation 91 8 is 35 
next. In operation 918, there is a test to determine if the 
value of number_entries_syncFIFO is less than the val- 
ue of ideaLentries_syncFIFO. If the value of 
number_entries_syncFIFO is not less than the value of 
ideaLentries_syncFIFO, then operation 922 is next. If 40 
the value of number_entries_syncFIFO is less than the 
value of ideal_entries_syncFIFO; then operation 920 is 
next. In operation 920, an idle packet is fed to the core 
of receiving chip 500, without pulling any packet from 
the synchronizing FIFO, and the test of operation 918 is *s 
repeated. In operation 922, a packet entry is pulled from 
the synchronizing FIFO and the address in the 
read_pointer is incremented. The next operation is op- 
eration 924, in which a test is made to determine if this 
is a drop-me packet. If it is not a drop-me packet, then so 
operation 91 0 is next. If it is a drop-me packet, operation 
922 is repeated. ... 
[0044] The discussion above has used a single trans- 
mitting chip and a single receiving chip as an example 
of a communication channel. However, alternative em- 55 
bodiments of the invention could be implemented on 
more than one transmitting chip and more than one re- 
ceiving chip. Additionally, alternative embodiments 



could be implemented for communication channels for 
systems that are not incorporated on individual IC chips. 
[0045] The most preferred embodiments of the inven- 
tion use FIFO buffers to implement the synchronizing 
buffer 502 (shown in FIG. 5). However, alternative em- 
bodiments could use other types of memory (e.g., ran- 
dom access memory, programmable memory such as 
flash memory, magnetic memory, and so forth) to imple- 
ment the synchronizing buffer 502. Alternative embodi- 
ments of the invention could use multiple synchronizing 
buffers to achieve one or more benefits, such as timing 
benefits. Furthermore, the preferred embodiments of 
the invention use a synchronizing sequence consisting 
of contiguous drop-me warning packets and drop-me 
packets between transactions.. However, alternative 
embodiments could use alternative sequences of drop- 
me warning packets and drop-me packets, or only con- 
tiguous drop-me packets between transactions. 
[0046] The exemplary embodiments described herein 
are for purposes of illustration and are not intended to 
be limiting. Therefore, those skilled in the art will recog- 
nize that other embodiments could be practiced without 
departing from the scope and spirit of the claims set forth 
below. 



Claims 

1. A method for preventing packet underflow and 
packet overflow for packets sent across an asyn- 
chronous link between a transmitter (400) and a re- 
ceiver (500), wherein said receiver (500) includes a 
buffer (502) that can store a number of packets 
greater than an ideal number of packets, said meth- 
od comprising: 

sending a predetermined number of drop-me 
warning packets (616) from said transmitter 
(400) to said receiver (500) across said asyn- 
chronous link; 

sending one or more drop-me packets (620) 
from said transmitter (400) to said receiver 
(500) across said asynchronous link; 
receiving said predetermined number of drop- 
me warning packets (71 2) and said one or more 
drop-me packets in said buffer (502) in said re- 
ceiver (500); 

compensating for said packet overflow (716) 
when said number of packets in said buffer 
(502) is greater than said ideal number of pack- 
ets by skipping at least one drop-me packet in 
said buffer (502) in said receiver (500): so that 
said ideal number of packets is substantially 
maintained in said buffer (502); and 
compensating for said packet underflow (720) 
when said number of packets in said buffer 
(502) is less than said ideal number of packets 
by stalling access to said buffer (502) for one 
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or more clock cycles, so that said ideal number 
of packets is substantially maintained in said 
buffer (502). 

2. The method of claim 1 , wherein said step (720) of 
compensating for packet underflow further compris- 
es injecting idle packets in said receiver (500). 

3. The method of claim 1 , wherein said predetermined 
number of drop-me warning packets is zero, and the 
first drop-me packet of said one or more drop-me 
packets is treated as a drop-me warning packet. 

4. The method of claim 1 , wherein one or more pack- 
ets from a header and zero or more data packets 
sent from said transmitter (400) to said receiver 
(500) correspond to a transaction, and said step 
(616) of sending a predetermined number of drop- 
me warning packets further comprises sending said 
predetermined number of drop-me warning packets 
after a first transaction is completed and before a 
second transaction begins. 

5. An asynchronous link for packets sent between a 
transmitter (400) having a first clock and a receiver 
(500) having a second clock, comprising: 

a buffer (502) to receive said first clock from 
said transmitter (400) and receive from said 
transmitter (400) a number of said packets 
equal to or different from a predetermined ideal 
number of packets; 

a read pointer (51 0) containing a read address 
for said buffer (502) and a read pointer control 
circuit (51 2) to change said read address in said 
read pointer (510), wherein said buffer (502) 
can receive a plurality of drop-me packets and 
said read address in said read pointer (51 0) can 
skip at least one drop-me packet in said buffer 
(502); and 

a write pointer (51 4) containing a write address 
for said buffer (502). 

6. The asynchronous link of claim 5, further compris- 
ing a circuit (508) to compensate for said packet 
overflow when said number of packets is greater 
than said predetermined ideal number of packets 
by skipping at least one drop-me packet in said buff- 
er (502) in said receiver (500). 

7. The asynchronous link of claim 5, further compris- 
ing a circuit (508) to compensate for said packet un- 
derflow when said number of packets is less than 
said predetermined ideal number of packets by 
stalling access to said buffer (502) for one or more 
second clock cycles in said receiver (500). 

8. The asynchronous link of claim 5, wherein said buff- 
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er (502) to receive said number of packets is a syn- 
chronizing First-In-First-Out (FIFO) buffer. 

The asynchronous link of claim 5, further compris- 
ing drop-me packet control logic (508) to change an 
address in said read pointer (510) by providing an 
input signal to said read pointer control circuit (51 2). 

A computer with program-controlled circuitry to re- 
duce underflow and overflow of a plurality of pack- 
ets sent from a transmitter (400) having a first clock 
and a receiver (500) having a second clock, com- 
prising: 

a buffer (502) to receive said plurality of packets 
and receive said first clock from said transmitter 
(400); 

a read pointer (510) containing a read address 
for said buffer (502) and a read pointer circuit 
(512) to change said read address in said read 
pointer (510); and 

a write pointer (51 4) containing a write address 
for said buffer (502). 
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